Existing mobile data access systems, such as the system and method described by U.S. Patent Pub. No. 2008/0134347 A1, provide security of on-device data by utilizing a lease key. The lease key acts as a temporary security token on a mobile device that can grant access to data that has been downloaded to the same mobile device. A lease key is issued to a mobile device, and permission to download the data to the mobile device is granted only when the user has authenticated successfully to the data provider.
Specifically, a backend security process is established whereby a specific user is associated with a specific mobile device and also associated with access permissions to particular dataset(s).
The user connects to the backend infrastructure from the assigned device and initiates a procedure that authenticates the user/device pair to the backend infrastructure and allows the creation of an initial lease key and the download of a requested dataset. The lease key is a data structure that incorporates both the public key that is be used to decrypt the data and an expiration date/time after which it cannot be used to decrypt the dataset. This data structure is designed such that attempts to decrypt the data will fail if the system clock shows a current date/time that is later than the lease key expiration date at the time that a decryption is attempted. The private key is kept secure in the data provider's backend infrastructure.
The private key associated with the created lease key is used to encrypt the requested dataset. The encrypted data and the public lease key are downloaded to the mobile device. At this point, the user can access the protected data on the mobile device until the lease key's expiration date/time is encountered. When the lease key expires, however, a routine attempt to access or decrypt the dataset will fail. This failure triggers a lease key renewal process that attempts to create a new lease key with a later expiration date/time.
In present systems, the renewal process requires a user interaction to manually re-authenticate to the backend server. This requires that the mobile device must be connected to a network. If the mobile device is not and cannot be connected to a network, the renewal process will fail and the user will be denied access to the data. If the mobile device is connected to a network, the user is prompted to connect to the data provider's backend infrastructure (i.e., backend server) and to manually re-enter his/her user credentials (i.e., domain name, user name, and password). If necessary or requested, this process can also download updates to the dataset. The result of a successful renewal is that all associated data (i.e., data already on the mobile device and any new updates provided to the mobile device) are encrypted with respect to the new lease key and new expiration date/time.
Therefore, while the current lease key system provides an effective system and method for protecting data that has been downloaded to the mobile device for the duration of the lease key's lifespan, when the lease key expires, it is necessary for the mobile device user to re-establish that he/she has permission to access the data on the device, and, perhaps, to update the data on the device. This current process of re-establishing access is cumbersome and somewhat intrusive to users since access to the data is blocked until the user completes this re-authentication process which, typically, requires a network connection to the backend infrastructure and an explicit user action (e.g., entering at least the user's password).
Satisfying the user in terms of ease-of-use or ease-of-access can be accomplished by minimizing the barrier to data access. However, previously proposed solutions to this problem either sacrifice security in the interests of increased user convenience, or sacrifice user convenience in the interests of increased security.
In present systems, creating or renewing the lease key utilizes a normal authentication process whereby the mobile device user knows his/her user credentials (i.e., domain, user name, and password) and enters them on a login form while connected to the backend infrastructure. This is a relatively weak authentication method since it only requires one authentication factor (i.e., the user credentials).
Moreover, by relying on the user to re-authenticate to the backend infrastructure utilizing only his/her credentials, present systems and methods for creating the lease key (for initial creation or renewal) do not fully meet the criteria for two-factor authentication. Two-factor authentication is an authentication process that utilizes at least two authentication factors, such as information that the user knows (e.g., user credentials); an object or thing that the user possesses (e.g., an accessory to the mobile device, such as a headset); or a unique and naturally occurring feature that the user possesses (e.g., a fingerprint, a retina).
Furthermore, in current systems, two-factor authentication is regarded as a simple extension of one-factor authentication. In one-factor authentication, anyone or anything that can provide one acceptable authentication factor is deemed to have satisfied the test for authentication. Easily compromised passwords (simply constructed or conspicuously written down) have led to the belief that it is often too easy for one authentication factor to become known. Therefore, in a two-factor authentication scheme, the user is asked to provide two authentication factors in which each authentication factor provides (implicitly in the way it is used) 50% of the evidence needed to satisfy the authentication test. Thus, the simple combination of 50% from each of the two factors results in 100% of the evidence needed to authenticate a user.
Mobile device users, in particular, present a more dynamic model of what constitutes authentication. Rather than requiring a user to provide exactly two authentication factors, users are working in a dynamic environment wherein he/she may be associated with one or more accessory devices that can themselves act as authentication factors. However, each of these accessory devices may have a varying degree of trustworthiness, which is how much the particular accessory can or should contribute to the system's overall confidence that the corresponding user should be authenticated (with the degree of trustworthiness based on factors including the accessory's presence in the system and the accessory's ability to pass a challenge/response test). The scenario is further complicated by the fact that, at any given moment, it could be that only one of several possible accessories is available in the environment for inclusion in authentication testing (e.g., some of the accessories may be turned off or be in a different physical location from the user).
Accordingly, there is a need for a system and method that utilizes an authentication and re-authentication process that fully implements two-factor authentication. There is a further need for a system and method whereby the authentication process is not only improved, but user interruption when the re-authentication process is triggered by the lease key expiration is also minimized. There is a further need for a dynamic authentication system and method that can be utilized with mobile devices and mobile device accessories.